The present invention relates to equipment and method for providing service in a mobile communications network. More particularly, it relates to a multicast processing server in a mobile communications system. What is referred to as “mobile communications network” here means a broadcast and multicast communications-capable mobile communications system.
3GPP2 (: 3rd Generation Partnership Project 2) is the international standardization alliance, whose target is to develop system structure and standards of the 3rd-generation mobile communications network. These standards are applied to the network of CDMA2000 aerial interface. In the 3GPP2 alliance, broadcast/multicast service (BCMCS) of CDMA2000 has been proposed. BCMCS addresses and executes one-point-to-plural-points transmission of multimedia data transmitted from a single source-node. The main object of BCMCS is to make the optimum use of aerial interface resources of CDMA2000, when the BCMCS multimedia data is transferred to one or plural mobile terminals in the CDMA2000 network system of a provider.
FIG. 1 is a schematic diagram for illustrating distribution of BCMCS-system function nodes proposed by the 3GPP2 alliance. FIG. 3 illustrates transfer mechanism of a BCMCS packet based on 3GPP2-compatible X. S0022 and A. S0019. One BCMCS_FLOW_ID is assigned to each BCMCS data flow (which corresponds to one multicast address and port). In the access network, the BCMCS data flows are transferred in such a manner that they are encapsulated into generic routing encapsulation (GRE) tunnels. The BCMCS data flows and the GRE tunnels are strictly brought into a one-to-one correspondence relationship with each other. One GRE identifier (GRE key or GRE ID) exists for each GRE tunnel. In other words, the GRE identifiers, the BCMCS_FLOW_IDs, and the BCMCS data flows are strictly brought into a one-to-one correspondence relationship with each other.
In FIG. 1, a source media flow is transmitted from a BCMCS contents provider 104. A BCMCS contents server 6 receives source media flows transmitted from a plurality of BCMCS contents providers 104, then processing the source media flows. After that, the server 6 transfers generated BCMCS data flows to a CDMA2000 Radio Access Network (RAN) via a multicast service node (BSN) 4. Every packet control function unit 5 (PCF) and every base station/base-station controller (BS/BSC) equipment 9 can create and deliver backups of an IP multicast packet. A BCMCS controller 8 is a piece of core net equipment, and its function is to manage BCMCS-session-related information, and to provide the information to a packet data service node (PDSN) 3, the multicast service node 4, mobile terminals 10, and the BCMCS contents server 6. The BCMCS controller 8 transmits the BCMCS-session-related information to the packet data service node 3 and the multicast service node 4 via an interface 102 and by way of an authentication-authorization-accounting server 1. An interface 103 is used for providing already-existing BCMCS-session-related information to the mobile terminals 10. This interface is referred to as “BCMCS information acquisition interface” as well. Also, the BCMCS controller 8 is in charge of security function partially, such as generating security keys and distributing the keys to the mobile terminals 10. The BCMCS controller 8 also performs authentication with respect to the BCMCS contents providers 104, thus allowing the BCMCS contents server 6 to control the BCMCS contents providers 104 to transfer the source media flows.
FIG. 2 is a diagram for illustrating an embodiment of cluster-communications system application based on BCMCS. This is an embodiment resulting from setting PoC (: Push-to-Talk over Cellular) as a cluster application. Assume that three clusters exist in PoC. Session control is performed based on Session Initiation Protocol (SIP), and management within each cluster is performed based on Real Time Control Protocol. In FIG. 2, reference numeral 6 denotes a cluster server, which has functions corresponding to those of the BCMCS contents server 6 and the BCMCS contents providers 104 in FIG. 1. Numeral 2 denotes a unicast packet control function unit for controlling a unicast packet. Numeral 7 denotes a SIP server, which has a session-establishing function.
In FIG. 2, there exist two base stations 9 which are in charge of two independent honeycomb cells 10. Two cluster mobile terminals 11 exist within each cluster. When one mobile terminal 11 within a cluster talks, the mobile terminal 11 transmits a unicast data flow to the cluster server 6 via an ascendant link of the mobile communications network. Having received the unicast data flow from the mobile terminal 11, the cluster server 6 checks the session information first. After that, the cluster server 6 transmits the corresponding contents to the mobile communications network by multicast communications. The multicast packets are captured by a multicast service node 4, thereby being transferred to the access network of the mobile communications network in a manner of being encapsulated. The IP multicast flows corresponding to the cluster are converted into BCMCS data flows by being processed by a packet control function unit 5 and a base station/base-station controller 9. After that, the BCMCS data flows are transmitted to BCMCS channels of aerial interface. Monitoring the aerial interface channel corresponding to the cluster allows the mobile terminal 11 within the cluster to receive data within the cluster. Accordingly, the aerial interface resources within the mobile communications network can significantly be saved by supporting the cluster service based on BCMCS.
FIG. 3 is the diagram for illustrating the flow of the BCMCS data transfer in the embodiment in FIG. 2. When the three clusters exist, the cluster server 6 transmits three multicast data flows to the mobile communications network. As a result, three BCMCS data flows exist correspondingly in the access network. The BCMCS data flows are encapsulated into the GRE tunnels 13. The BCMCS data flows and the GRE tunnels are brought into a one-to-one correspondence relationship with each other.
In the base station/base-station controller 9, reserve of the aerial interface resources is performed based on the GRE tunnels. In the present embodiment, if a certain base station can support only 192-kbps BCMCS flow amount, and if the base station is required to support the three BCMCS data flows, flow amount of each BCMCS data flow must be smaller than 64 kbps. In the case of PoC, if a member to talk with does not exist within a certain cluster, data to be transmitted within the cluster does not exist, either. If a member to talk with does not exist in all of the cluster communications groups, the aerial interface resources reserved will be wasted.
Also, if the present base station can support only 128-kbps BCMCS rate at the maximum, and if bandwidth of each cluster communications group is equal to 80 kbps at the minimum (i.e., when G.711 voice code is used), the base-station controller (BSC) 9 finds it impossible to assign the aerial interface resources to the three cluster communications groups, but finds it possible to assign the aerial interface resources to only one BCMCS data flow (which corresponds to one cluster communications group). Also, when a plurality of GRE tunnels are in a one-to-one correspondence relationship with a plurality of BCMCS data flows, the base station/base-station controller 9 is required to create and manage a plurality of buffering queues correspondingly, and to manage all of the GRE tunnels and buffering queues by performing a large number of complicated manipulations. This requirement, in some cases, delays transfer of the BCMCS data, thereby exerting an influence on performance of the cluster communications. It is conceivable that this influence is not at all negligible for the cluster communications, i.e., the delay-sensitive application.
FIG. 4 is a diagram for illustrating format of an IP packet of the multicast data flow. This is the standard IP multicast packet. A source address 121 is an IP address of the cluster server 6. A destination address 122 is multicast addresses assigned to the cluster communications groups. Pure load 123 of the IP multicast packet plays a role of transferring the session data. Packet format of the BCMCS data flow is basically the same as that of the IP multicast data flow.
FIG. 5 is a diagram for illustrating IP packet format of the GRE tunnel in the access network. The GRE tunnel is a method for implementing the general-purpose encapsulation. Start portion of the GRE packet head is a partial GRE data field used for storing a certain protocol and strategy. GRE identifier (GRE ID) 136, which is an identifier for the GRE tunnel, is uniquely assigned into cover area of a certain access network. The multicast packet is encapsulated into the IP multicast packet 122.
FIG. 6 is a diagram for illustrating the situation of representative data flow in the PoC service. Here, there is an exceedingly important feature that, if no one is talking within a cluster, no data will be transferred within the cluster. In this case, the aerial interface resources assigned to the cluster service will completely be wasted. In the 3GPP2 alliance, the multicast node server finds it impossible to grasp usage situation of the BCMCS resources at a related base station. As a result, the multicast node server can perform only the transfer of a simple BCMCS frame, thus finding it impossible to perform further analysis and scheduling.